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SYNCHRONIZATION OF DATABASES 
Background 
This invention relates to synchronizing 
5 incompatible databases. 

Databases are collections of data entries which 
are organized, stored, and manipulated in a manner 
specified by applications known as database managers 
(hereinafter also referred to as "Applications" ; 

10 hereinafter, the term "database" also refers to a 

database manager combined with a database proper) • The 
manner in which database entries are organized in a 
database is known as the data structure of a database • 
There are generally two types of database managers. 

15 First are general purpose database managers in which the 
user determines (usually at the outset, but subject to 
future revisions) what the data structure is. These 
Applications often have their own programming language 
and provide great flexibility to the user. Second are 

20 special purpose database managers that are specifically 
designed to create and manage a database having a preset 
data structure. Examples of these special purpose 
database managers are various scheduling, diary, and 
contact manager Applications for desktop and handheld 

25 computers. Database managers organize the information in 
a database into records , with each record made up of 
fields. Fields and records of a database may have many 
different characteristics depending on the database 
manager's purpose and utility. 

30 Databases can be said to be incompatible with one 

another when the data structure of one is not the same as 
the data structure of another, even though some of the 
content of the records is substantially the same. For 
example, one database may store namies and addresses in 

35 the following fields: FIRST_NAME, LAST__NAME, and 
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ADDRESS* Another database may, however, store the same 
information with the following structure: NAME, 
STREET^NO., STREET_NAME, CITY_STATE, and ZIP. Although 
the content of the records is intended to contain the 
5 same kind of information, the organization of that 
information is completely different. 

Often users of incompatible databases want to be 
able to synchronize them with one another- For example, 
in the context of scheduling and contact manager 

10 Applications, a person might use one Application on the 
desktop computer at work while another on his handheld 
computer or his laptop computer while away from work. It 
is desirable for many of these users to be able to 
synchronize the entries on one with entries on another. 

15 The U.S. patent and copending patent application of the 
assignee hereof. Puma Technology, Inc. of St. Jose, 
California (U.S. Patent No. 5,392,390 (hereinafter, "the 
'390 patent"); U.S. Application, Serial No. 08/371, 194, 
filed on January 11, 1995, incorporated by reference 

20 herein) show two methods for synchronizing incompatible 
databases and solving some of the problems arising from 
incompatibility of databases. 

Synchronization of two incompatible databases 
often requires comparrison of their records so that they 

25 can be matched up prior to synchronization. This may 
require transferring records in one database from one 
computer to another. However, if the data transfer link 
between the two computers is slow, as for example is the 
case with current infrared ports, telephone modem, or 

30 small handheld computers, such a transfer increases the 
required time for synchronization by many folds. 

Summary 

In one general aspect, the invention provides for 
using certain design characteristics of certain 
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Applications to speed up the synchronization process. 
Some Applications provide information for keeping track 
of which records were changed, deleted, or added since 
the last synchronization. The invention uses these 
5 features to speed up the synchronization process by 

retrieving only those records which have been changed or 
addied since a previous synchronization. 

The invention provides a computer implemented 
method and a computer program for synchronizing a first 

10 and a second database* Based on data reflecting whether 
the records of the first database have been added or 
changed since a previous synchronization, it is 
determined whether the records of the first database have 
been changed or added since the previous synchronization. 

15 If one of the records of the first database has not been 
changed or added since the previous synchronization, a 
synchronization with records of the second database is 
performed using a .record representative of the one record 
at the time of a previous synchronization. The 

20 representative record is stored in a history file which 
contains records reflecting the contents of records of 
the databases at the time of a previous synchronization. 

Preferred embodiments of this aspect of the 
invention may include one or more of the following 

25 features. The data provided for keeping track of 

whether the records of the first database have been added 
or changed since a previous synchronization may be 
database generated data, stored in the records of the 
first database. 

30 The computer generated data indicates the most 

recent date and time of when a record was created or 
changed. The computer generated data includes a flag set 
when a record is created or changed. 

The first database provides further database 

35 generated data indicating which records were deleted 
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since the previous synchronization- Records of the 
history file corresponding to the deleted records are 
identified by performing a comparison of the further 
computer generated data with the history file* Records 
5 of the history file corresponding to records of the first 
database deleted since the previous synchronization are 
identified by performing a comparison of the records of 
the history file and a result of determining which of the 
records of the first database have been added or deleted. 

10 The first database assigns a unique identification 

data to the records of the first database. A comparison 
of the records of the history file is made to the unique 
identification data of records in the first database that 
have been changed or added since the previous 

15 synchronization. The synchronization is completed using 
a result of the comparison. 

Records of the first database and the history file 
are modified, added, or deleted based on the results of 
the synchronization. The history file contains records 

20 reflecting the contents of records of the databases at 
the time of the current synchronization. 

Embodiments of this aspect of the invention may 
include one or more of the following advantages. 

Some embodiments of the invention reduce the 

25 number of unchanged records that need to be read from the 
databases in order to synchronize the databases with one 
another. Typically a majority of the database records 
are unchanged. Therefore, not reading the unchanged 
record reduces the time required to synchronize the 

30 databases, especially where the data transfer link 

between the two computers which store the databases is 
slow. 

In another general aspect, the invention features 
a computer implemented method for synchronizing a first 
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database located on a first computer and a second 
database located on a second computer. At the first 
computer, it is determined whether a record of the first 
database has been changed or added since a previous 
5 synchronization, using a first history file located on 
the first computer comprising records representative of 
records of the first database at the completion of the 
previous synchronization. If the record of the first 
database has not been changed or added since the previous 
10 synchronization, the first computer sends the second 
computer information which the second computer uses to 
identify the record of the first database to be 
unchanged. 

The embodiments of this aspect of the invention 

15 may include one or more of the following features. 

A second history file may be located on the second 
computer • The second history file contains records 
representative of records of the first database at the 
completion of the previous synchronization, where one of 

20 the representative records represents the record of the 
first database determined to be unchanged. Then, at the 
second computer, a synchronization of the second and 
first databases is performed using the one of the 
representative records . 

25 The information sent from the first computer to 

the second computer can be used to locate the one of the 
representative records in the second history file. The 
second history file can store infoirmation in relation to 
the representative records and the one of the 

30 representative records in the second history file can be 
identified from that stored information. Additionally, 
the information sent from the first computer to the 
second computer can include information that matches the 
information stored in relation to the one of the 

35 representative records in the second history files. 
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The information sent to the second computer can 
include information identifying records other than the 
unchanged record* It can also include information 
identifying the changed record- It can also include 
5 information identifying the deleted records or added 
records. The information can also include a code based 
on at least a portion of the content of the record of the 
first database. The code may be a hash number. The 
information may be a code uniquely identifying the record 
10 of the first database. Such a code may be one assigned 
by the first database to the records. 

In another aspect, the invention features a 
computer implemented method of identifying a record of a 
database. A record of the database is read. A code is 
15 assigned to the record of the database, the code being 
based on at least a portion of the content of the record 
of the first database. The code is then to identify the 
record at a later time. 

The embodiments of this aspect of the invention 
20 may include one or more of the following features. 

The code may be a hash number computed based on at 
least a portion of the content of a record of the first 
database. 

The database is stored on a first computer and the 
25 code is transmitted to a second computer to identify the 
record to an application. 

Advantages of these aspects of the invention may 
include one or more of the following advantages. 

When synchronization is performed using the 
30 invention, a data transfer link, specially a slow data 
transfer link, is used efficiently, since unchanged 
records that are typically the majority of the records in 
a database are not transferred between the two computers. 
Hence, when synchronizing two databases on two different 
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computers, the time needed to synchronize the two 
databases is decreased 

Also, when transmitting data from one computer to 
another, using a content based code, that requires less 
5 bandwidth for being transmitted and nonetheless 

identifies a record, results in a slow data transfer 
links being used more efficiently. 

The invention may be implemented in hardware or 
software, or a combination of both- Preferably, the 

10 technique is implemented in computer programs executing 
on programmable computers that each include a processor, 
a storage medium readable by the processor (including 
volatile and non-volatile memory and/or storage 
elements) , at least one input device, and at least one 

15 output device. Program code is applied to data entered 
using the input device to perform the functions described 
above and to generate output information. The output 
information is applied to one or more output devices. 

Each program is preferably implemented in a high 

20 level procedural or object oriented programming language 
to communicate with a computer system. However, the 
programs can be implemented in assembly or machine 
language, if desired. In any case, the language may be a 
compiled or interpreted language, 

25 Each such computer program is preferably stored on 

a storage medium or device (e.g., ROM or magnetic 
diskette) that is readable by a general or special 
purpose programmable computer for configuring and 
operating the computer when the storage medium or device 

30 is read by the computer to perform the procedures 
described in this document. The system may also be 
considered to be implemented as a computer-readable 
storage medixrm, configured with a computer program, where 
the storage medium so configured causes a computer to 

35 operate in a specific and predefined manner. 
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Other features and advantages of the invention 
will become apparent from the following description of 
preferred embodiments^ including the drawings, and from 
the claims* 

5 Brief Description of the Drawing 

Figure 1 is a schematic drawing of the various 
modules constituting the preferred embodiment. 

Figure 2 is a representation of the Workspace data 

array . 

10 Figure 3 is the pseudocode for the Translation 

Engine control Module. 

Figure 4 is the pseudocode for loading records by 
a fast synchronization Translator. 

Figure 5 is the pseudocode for loading records by 
15 a fast synchronization Translator. 

Figure 6 is the pseudocode for loading records by 
a medium synchronization Translator and synchronizing by 
a synchronizer. 

Figure 7 is the pseudocode for loading records by 
20 an alternative medium synchronization Translator. 

Figure 8 is the pseudocode for an alternative 
method of loading records of a medium synchronization 
database. 

Figure 9 shows two computers connected via data 
25 transfer link. 

Figure 10 is a schematic drawing of the various 
modules constituting an alternative embodiment of the 
invention. 

Figure 11 is pseudocode for the Translation Engine 
30 Control Module. 

Figure 12 is pseudocode for a remote segment of a 
synchronization program when loading records from and 
unloading records to the remote database, when the 
database assigns unique IDs. 
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Figure 13 is pseudocode for a host segment of a 
synchronization program when loading records from and 
unloading records to the remote database, when the 
database assigns unique IDs. 

Figure 14 is pseudocode for a remote segment of a 
synchronization program when loading records from and 
unloading records to the remote database, when the 
database does not assign unique IDs. 

Figure 15 is pseudocode for a host segment of a 
synchronization program when loading records from and 
unloading records to the remote database, when the 
database assigns unique Ids. 

Description 

Briefly, a synchronization program 100 (Fig. 1) 
15 running on a computer loads records of two databases, 
e.g. a scheduling database on the computer and another 
one on a remote handheld or notebook computer. The 
synchronization program then synchronizes the records of 
those databases using a history file that contains 
20 records representative of the records of the two 

databases at the end of a previous synchronization. The 
synchronization program uses the history file to 
determine, for example, which records have been changed, 
added or deleted since the previous synchronization and 
25 which records of the two databases correspond to one 
another . 

If one of the databases has the capability to 
provide database generated information or data which can 
be used to determine, for example, whether a record has 
30 been changed, added, or deleted since a previous 

synchronization, the synchronization program uses that 

information to determine whether a record has been I 
changed, added, or deleted, of course, that database | 
generated information is less than the whole record of 

. I 



5 



10 
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the database. For example, that information may be a 
date and time stamp, or a flag, set when the record was 
last modified or when the record was added, whichever is 
later. 

5 There are generally two types of such databases: 

"meditim synchronization" and "fast synchronization" 
databases. A "fast synchronization" database is a 
database which provides information regarding changes, 
deletions, and additions to its records from one 

10 synchronization to the next. A fast synchronization 
database also assigns to each record of the database a 
unique identification code (i.e. a unique ID) which 
uniquely identifies that record. Unique IDs are required 
to accurately identify records over a period of time. A 

15 fast synchronization database also provides a mechanism 
for keeping track of which records are added, changed, or 
deleted from synchronization to synchronization, 
including a list of deleted records. 

A "medium synchronization" database typically has 

20 more limited capabilities than a fast synchronization 
database for keeping track of addition, deletions, or 
changes; In short, a medium synchronization database 
does not keep track of deletions. Such a database 
however still has the capability to provide information 

25 regarding what records were added or modified since a 
previous synchronization. A medium synchronization 
database also provides unique IDs. 

If the information provided by a database 
indicates that a record has not been changed or added 

30 since a previous synchronization, the synchronization 

program need not load that record and can use the history 
file to reconstruct the relevant contents of that record 
for synchronizing the two databases. The history file 
contains a copy of the relevant content of that record as 

35 the record was at the time of (e.g. at the end of) the 
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previous synchronization. Using the history file to 
reconstruct the record instead of loading the record can 
result in significant saving of time - where for example 
the data transfer link between the two computers is slow 
5 - since typically a majority of records in databases are 
unchanged records. The synchronization program thereby 
increases the efficiency of performing synchronization- 
between two databases. 

In order to better understand embodiments the 

10 invention described herein, we will briefly describe the 
overall structure of a synchronization program and the 
method it uses to synchronize databases, both of which 
are described in more detail in the following commonly 
owned UoS. patent applications, incorporated in their 

15 entirety by reference, "Synchronization of Recurring 
Records in Incompatible Databases", Serial no. 
08/752,490, filed on November 13, 1996 (hereinafter, 
"application M90"); "Synchronization of Databases with 
Record Sanitizing and Intelligent Comparison," Serial no. 

20 08/749,926, filed November 13, 1996 (hereinafter, 

"application '926"); "Synchronization of Databases with 
Date Range," Serial no. 08/748,645, filed November 13, 
1996 (hereinafter, "application '645") . We will then 
describe specifically how the synchronization program 

25 operates when at least one of the databases provides 
information indicating that records have been changed, 
added or deleted since a previous synchronization. 

Fig. 1 shows the relationship between the various 
modules of an embodiment of synchronization program 100. 

3 0 Translation Engine 1 comprises Control Module 2 and 
Parameters Table Generator 3. Control Module 2 is 
responsible for controlling the synchronizing process by 
instructing various modules to perform specific tasks on 
the records of the two databases being synchronized. 

35 (Fig. 3 shows the steps taken by this module.) The 
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Parameters Table Generator 3 is responsible for creating 
a Parameter^Table 4 which is used by all other modules 
for synchronizing the databases. Generally, 
Parameter^Table 4 stores various information which may be 
5 used by the modules of the synchronization program. The 
information stored in Parameter_Table 4 includes user 
preferences, the names and locations of the databases, 
and the names and locations of various files stored on 
disk including the name and location of the history file 

10 from the previous synchronization. 

Synchronizer 15 has primary responsibility for 
carrying out the core synchronizing functions. It is a 
table-driven code which is capable of synchronizing 
various types of databases whose characteristics are 

15 provided in the Parameter^Table 4 . Synchronizer 15 

creates and uses the Workspace 16 (also shown in Fig, 2), 
which is a temporary data array used during the 
synchronization process. 

A Translator 5 (A_Translator) is assigned to the 

20 A_database 13 and another Translator 9 (B_Translator) to 
the B_database 14 ^ Each of the database Translators 5 
and 9 comprises three modules: Reader modules 6 and 10 
(A_Reader and B_Reader) which read the data from 
databases 13 and 14; Unloader modules 8 and 12 

25 (AUnloader and B_Unloader) which analyze and unload 

records from the Workspace into databases 13 and 14; and 
Sanitizing modules 7 and 11 (A_Sanitizer and B_Sanitizer) 
which analyze the records of the opposing database when 
they are loaded into the Workspace and modify them 

30 according to rules of data value of the modules 's own 
database. Briefly stated, rules of data value are 
generally rules that define the permitted content of the 
fields of the records of a database. An example of such 
a rule would be that no more than 100 characters may be 

35 present in a field, or that content of a field 
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designating a priority for a "to do" item should be 
limited to l, 2, or 3. Sanitizing a record is to change 
the content of the fields of a record of one database to 
conform to the rules of data value of another database. 
5 Rules of data value and sanitization are described in 
detail in the '490, '926 and '645 applications. 

In the described embodiment, the modules of 
A^Translator 5 are designed specifically for interacting 
with A_database 13 and A_Application 17. Their design is 

10 specifically based on the record and field structures and 
the rules of data value imposed on them by the 
A_Application, the Application Program Interface (API) 
requirements and limitations of A_Application 17 and 
other characteristics of A_Database and A_Application. 

15 The same is true of the modules of B_Translator 9. These 
Translators are not able to interact with any other 
databases or Applications. They are only aware of the 
characteristics of the database and the Application for 
which they have been designed. Therefore, in the 

20 preferred embodiment, when the user chooses two 

Applications for synchronization, the Translation Engine 
chooses the two Translators which are able to interact 
with those Applications. In an alternate embodiment, the 
translators can be designed as table-driven codes, where 

25 a general Translator is able to interact with a variety 
of Applications and databases based on supplied 
parameters . 

Fig. 3 is the pseudocode for the described 
embodiment of Control Module 2 of the Translation Engine 

30 1. We will use this pseudocode to generally describe the 
steps taken when synchronizing two databases performed by 
the synchronization program 100. Control Module 2 first 
instructs the Parameter Table Generator 3 of Translation 
Engine 1 to create Parameter_Table 4 (Step 100) . In step 

35 102, the Translation Engine instructs synchronizer 15 to 
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load the history file. Synchronizer 15 in response 
creates the Workspace 16 data array and loads history 
file 19 into Workspace 16. History file 19 is a file 
that was saved at the end of last synchronization. It 
5 contains records representative of the records of the two 
databases at the end of the previous synchronization. 
The history file is necessary for use with the current 
synchronization. Generally, synchronization is a process 
of analyzing records from the A_Database and B_Database 

10 against the records of the history file to determine the 
changes, additions, and deletions in each of two 
databases since a previous synchronization and then 
determining what additions, deletions, or updates need be 
made to synchronize the records of the two databases. If 

15 no history file from a previous synchronization exists or 
the user chooses to synchronize not using the history 
file, step 102 is not performed. 

Once the history file is loaded into the 
Workspace, Control Module 2 instructs B_Translator 13 to 

2 0 load the B_Database records (step 103). B_Reader module 
11 of the B_Translator reads the B_dat abase records and 
sends them to synchronizer 15 for writing into the 
Workspace. Following loading the B_Database records 
("B_Records") , A_Sanitizer module 8 of A_Translator 5 

25 sanitizes the B_Records in the Workspace (step 104) . 
Control Module 2 of the Translation Engine 3 then 
instructs the A_TranslatGr 5 to load the records from the 
A_Database (step 105) . A__Reader module 7 of A_Translator 
5 reads the A_Database records ("A_Records") and sends 

30 them to synchronizer 15 for writing into the Workspace. 
B_Sanitizer module 12 of B_Translator 9 then sanitizes 
the A_Records in the Workspace. 

Records in the Workspace are stored according to 
the B_Database data structure. Therefore, as 

35 synchronizer 15 receives each A^record from the A_Reader 
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module 7 of the A__Translator 5, synchronizer 15 maps that 
record using an A-^B_Map before writing the record into 
the next available spot in the Workspace* Since the 
A_records are mapped into the B_Record format, when the 
5 B_Sanitizer is instructed by Control Module 2 to begin 
sanitizing those records and starts asking for them from 
synchronizer 15, they already hav^e the B_Database format. 
Therefore, synchronizer 15 does not need to map them 
before sending them to the B_Sanitizer module 12 of the 

10 B_Translator 19. For the same reason, there is no need 
for them to be mapped once they are sent back by the 
B__Sanitizer after having been sanitized- However, in the 
case of B_records, they must be mapped using a B-^A map 
prior to being sent to A_sanitizer and then mapped back 

15 using an A-*B map* At this point, all records are loaded 
into the Workspace. 

Synchronizer 15 then performs a Conflict Analysis 
and Resolution ("CAAR") procedure on the records in the 
Workspace, which procedure is described in detail in the 

20 '490, '^926 and '645 applications. Briefly, during this 
process, synchronizer 15 compares the records in the 
workspace and determines what synchronization actions 
should be taken. Synchronizer 15 processes the records, 
including comparing them to one another, in order to form 

25 them into groups of related records called corresponding 
item groups (CIGs) . Each GIG may comprise at most one 
recurring or a group of related nonrecurring records from 
each of the databases and the history file. After 
forming CIGs from all records of the two databases, 

30 synchronizer 15 compares the records in each GIG with one 
another, determines their differences, and decides what 
synchronization action should be taken. Synchronization 
actions with respect to a record include updating, 
deleting, adding, or not modifying that record. For 

35 example, if after comparing the records in a GIG, 
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synchronizer 15 determines that the record from 
A_dat abase is unchanged and the one from B_database is 
changed, synchronizer 15 determines that the A_database 
record should be changed to conform to the B_database 
5 record • Or, if both records are changed (an example of 
what we refer to as a "conflict" since there is no clear 
choice of synchronization action) , synchronizer 15 may 
use a user-selected rule to decide what synchronization 
should be taken. The rule may require, for example, not 

10 modifying either of the records, changing the B_database 
record to conform to the A_database record, or asking the 
user to resolve conflicts. 

When synchronizer 15 finishes performing CAAR on 
the records, synchronizer 15 would have determined what 

15 synchronization action should be taken with respect all 
records to be synchronized. The records may then be 
unloaded into their respective databases. The 
Translators will perform the specific synchronization 
actions to be taken with respect to the records of the 

20 databases. However, prior to doing so, the user is asked 
to confirm proceeding with unloading (steps 108-109) . Up 
to this point, neither the databases nor the history file 
have been modified. The user may obtain through the 
Translation Engine's User Interface various information 

25 regarding what synchronization actions will be taken upon 
unloading • 

If the user chooses to proceed with 
synchronization and to unload, the records are then 
unloaded. The Unloader modules 6,10 of the Translators 

30 5,9 perform the unloading for the databases. 

Synchronizer 15 creates the history file and unloads the 
records into the history file. Control Module 2 of 
Translation Engine 1 first instructs the B__Translator to 
unload the records from Workspace into the B_Database. 

35 Following unloading of the B_RECORDS, Control Module 2 
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instructs the A__Translator to unload the A_Records from 
the l^orkspace (step 111) • This unloading is done in the 
same way as it was done by the B_Translator . Control 
Module 2 next instructs synchronizer 15 to create a new 
5 history file (step 112) . During unloading, the Unloader 
module of the A_Translator uses the A-^B map the map the 
records in the Workspace into the format of A_database 
records . 

At this point Synchronization is complete. 

10 The speed of the above synchronization process can 

be improved in the case of databases which provide data 
for keeping track of which records have been changed/ 
added, deleted, or left unchanged since a previous 
synchronization. As previously described, there are 

15 generally two types of such databases: "medium 

synchronization" and "fast synchronization" databases. 

A "fast synchronization" database is a database 
which provides information regarding changes, deletions, 
and additions to its records from one synchronization to 

20 the next. Synchronization program 100 can use this 
information to speed up the synchronization process 
because records which have not been changed are not 
loaded from the database. Since the majority of records 
loaded by regular Translators are typically unchanged 

25 records, far fewer records are loaded from the database 
into Workspace than would otherwise be the case. 

Certain features are required for a database to be 
a fast synchronization database. The database assigns 
each record of the database a unique ID and provides a 

30 mechanism for keeping track of which records are added, 
changed, or deleted from synchronization to 
synchronization, including a list of deleted records. 

There are at least two ways to keep track of 
additions, changes, and deletions in a database. 
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First, some databases maintain one Dirty bit per 
record which is a boolean flag that is set when a record 
is created or modified and is cleared when a function for 
clearing Dirty bits is called. Some databases offer a 
5 Clear DirtyBits function that clears a Dirty bits of an 
individual record. Other databases offer a 
ClearDirtyBits function that clears the Dirty bits of all 
records in a database. The record-specific ClearDirtyBit 
function allows the described embodiment to use the 

10 database itself to keep track of additions and changes. 

The global ClearDirtyBits function forces the 
described embodiment to clear all Dirty bits at the 
conclusion of every Synchronization. Then as database 
edits are made by the user in between synchronization, 

15 the affected records are marked as Dirty. When 
Synchronization is performed again, only the Dirty 
records are loaded. 

Second, some databases maintain a date and time 
stamp of when the record was added or last time the 

20 record was modified. A Translator for such a database 
finds all records which were added or modified since the 
previous synchronization by searching for date and time 
stamps more recent than the Date&Time of the Last 
Synchronization. 

25 A fast synchronization database must also keep 

track of deletions. This is done by maintaining a list 
of deleted records which can be read by a Translator. 

A Translator sending fast synchronization database 
records to synchronizer 15 provides only records which 

30 have been changed, deleted, and added since the previous 
synchronization. Therefore, unlike a regular database 
Translator, a fast synchronization database Translator 
does not provide synchronizer 15 with unchanged records. 
Moreover, unlike a non-fast synchronization Translator, a 
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fast synchronization translator provides deleted records^ 
which the regular Translators does not. 

In order for such databases to be synchronized 
without resorting to treating them as regular databases 
5 (necessitating loading all records) , synchronizer 15 

transforms fast synchronization database records from the 
Translator into equivalent regular database records. 
These transformed records are then used by synchronizer 
15 in the synchronization process. There are two 

10 transformations which are necessary • First, synchronizer 
15 needs to transform deleted records received from the 
fast synchronization Translator into a regular database 
deletions. Second, synchronizer 15 needs to transfora 
lack of output by the fast synchronization Translator 

15 into unchanged records. 

Synchronization program 100 performs these 
transformations by using the history file. When the 
databases are synchronized for the first time, all 
records in the fast synchronization database are loaded 

20 into the history file. As changes, additions, and 

deletions are made to the fast synchronization database, 
during each of the subsequent synchronization, the same 
changes, additions, and deletions are made to the history 
file. "Therefore, the history file at the end of each 

25 subsequent synchronization contains a copy of the data in 
the fast synchronization database. 

When a fast synchronization database Translator 
supplies no input for a unique ID history file record, 
synchronizer 15 finds (i.e. identifies) the corresponding 

30 history file record in Workspace 16, copies it into 

Workspace 16, and treats the copied record as if it were 
loaded by the fast synchronization translator itself. 

Referring to Fig. 4, steps 1050-1051, synchronizer 
15 first verifies that there is an appropriate history 

35 file. Because synchronization of fast synchronization 
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databases relies heavily on the history file, it is 
important to ensure that the same history file as the 
last Synchronization is usedo Moreover, the history file 
is the background against which the transformation of the 
5 Translator outputs into regular Translator outputs takes 
place. The history file keeps a date and time stamp of 
the previous synchronization. Each of the fast 
synchronization database (if able to) and the fast 
synchronization Translator also stores the same date and 

10 time stamp. The date and time stamp is used because it 
is unlikely that another history file will have exactly 
the same date and time entry, for the same two databases. 
The date and time stamp also identifies when last the 
fast synchronization database and the history file 

15 contained the same records. 

At the start of synchronizing a fast 
synchronization database with another database, 
synchronizer 15 and the fast synchronization Translator 
compare date and time stamps. If the date and time stamp 

20 have changed since the previous synchronization, then the 
synchronization proceeds from scratch (step 1052). In a 
synchronization from scratch all records of the fast 
synchronization database are loaded into Workspace 16 and 
a history file is not used. 

25 In the described embodiment, all records supplied 

as fast synchronization inputs have a special hidden 
field called _Delta, which carries a single-letter value 
- 'D' for deleted, ^A' for added, and for changed. 
Records are loaded by the fast synchronization Translator 

30 into Workspace 16 (step 1054). If necessary, the 

records are mapped when loaded. Records which are marked 
as changed or added are sanitized by the Translator for 
the other database , but deleted records are not because 
their field values are going to be deleted (step 1055) . 

35 Orientation analysis, details of which are described in 
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the M90, '926, and '645 applications, is performed on 
the records. In general terms, during orientation 
analysis, deletions and changes to fast synchronization 
database records are joined with their history file 
5 counterparts in unique ID bearing CIGs (step 1107). 
These are CIGs in which at least one of the records is 
assigned a unique ID. Synchronizer 15 may treat these 
CIGs differently than other CIGs to improve the 
efficiency of the synchronization program, for example, 

10 by matching them to history file records based on their 
unique ID value instead of the content of record, as 
described in detail in applications '490, '926, and '645. 

All history file records and their CIGs are now 
examined. If there is no corresponding record from the 

15 fast synchronization database, it means that the record 
was unchanged. A clone of the record is made, labelled 
as being from a fast synchronization database, and joined 
to the history file record's CIG. At this point the 
deleted fast synchronization database records marked as 

20 deleted are removed from CIGs (step 1109) . The fast 
synchronization records marked as changed are joined in 
doubleton CIGs (i.e. CIGs entry records from two 
databases). Those marked as additions are singletons. 
At this point, the synchronization can proceed as if 

25 record of a unique ID bearing regular database were just 
loaded into Workspace 16. 

Whenever records are loaded from a fast 
synchronization database, all records are loaded so that 
at the end of synchronization the history file will be 

30 the same as the fast synchronization database. 

Therefore, referring to Fig. 5, in order to perform date 
range limited synchronization, synchronizer 15 marks the 
records which fall outside the current and the previous 
date ranges. A record marked as an added, or during 

35 synchronizing from scratch, a record that falls outside 
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the current date range, it is marked as Out_Of_Range 
(steps 1101 and 1153-1154). This record will be written 
into the history file but not into the other database or 
take part in synchronization. When the fast 
5 synchronization database records are loaded from the 
history file, if they fall outside of the previous date 
range, they are marked as Bystander (steps 1152-1157). 
If a Bystander record forms a CIG with a fast 
synchronization record marked as a deletion or a change, 

10 the Bystander is marked with a Garbage flag because its 
field values serve no useful purpose any more: the 
record marked as DELETION should be deleted and the 
record marked as CHANGED should replace the Bystander 
history file record (step 1162) . 

15 History file records for which there are no inputs 

are transformed in the same manner as before (steps 1164- 
1165). If a Bystander record falls within the current 
date range, it is equivalent to a regular database record 
coming into the current date range. Therefore, the 

20 history file record is cloned and marked as a fast 
synchronization database record while the Bystander 
record is marked as Garbage (steps 1166-1171). 
Therefore, just like a new record of a regular database, 
the record has no history file record counterpart. 

25 If the user selects to abort a synchronization or 

selects the option to ignore a conflict or conflicts in 
general, some of the records loaded from the fast 
synchronization database will not be accepted and 
recorded in the history file. Therefore, the Translator 

30 should provide that record again during the next 

synchronization. However, because fast synchronization 
Translators supply only records which have been changed, 
deleted, or added since the previous synchronization, the 
records which were not accepted will not be supplied 

35 since they remain unchanged. To circumvent this, the 
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fast synchronization Translator waits for an 
acknowledgement from synchronizer 15 that the record has 
been accepted. 

In the case no such acknowledgement is received 
5 for a record, the Translator needs to be able to provide 
that record again to synchronizer 15. If the database 
allows resetting individual Dirty bits, the Translator 
merely does not set that bit. If not, the Translator 
keeps a separate file in which it keeps a record of which 

10 fast synchronization records were not accepted. The file 
may contain the unique IDs of those records. The 
Translator then uses that file to provide synchronizer 15 
with those records during the next synchronization. 

We will now describe synchronization in the case 

15 of medium synchronization databases. Medium 

synchronization databases have more limited capabilities 
than fast synchronization databases for keeping track of 
addition, deletions, or changes. Medium synchronization 
database do not keep track of deletions. They however 

20 still have the capability to provide information 

regarding what records were added or modified since a 
previous synchronization. This information typically 
takes the form of date and time stamps stored with the 
record or a Dirty bit, as previously described. 

25 In the case of medium synchronization databases, 

the Translator provides synchronizer 15 with information 
indicating which records have been added/changed and 
which records are unchanged. Based on this information 
and the history file, synchronizer 15 determines which 

30 records were deleted. Synchronizer 15 assumes that those 
records in the history file for which no matching unique 
ID was obtained from the database are deleted records and 
flags them as such. In identifying a record as having 
been deleted from the database, synchronizer 15 can 

35 easily determine what synchronization action should be 
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taken with respect to the counterpart of that record in 
the other database; such action may be to delete the 
other record. Those records whose unique IDs do not match 
the unique IDs of the history file records are new 
5 records and synchronizer 15 marks them specifically as 
" added " records . 

Synchronizing medium synchronization databases, 
like in the case of fast synchronization databases, 
relies on the history file. Therefore, the description 

10 of the history file and its treatment in the case of fast 
synchronization databases equally applies to the case of 
medium synchronization databases. 

Fig. 6 shows the pseudocode for the steps taken by 
a translator for a medium synchronization database that 

15 uses a date and time stamp to provide information 
regarding whether a record has been changed or added 
since a previous synchronization. For every record in 
the database, the translator gets the unique ID and the 
date and time stamp of that record (steps 1200-1202). If 

20 the date and time stamp is prior to or at the same time 
as the date and time of the previous synchronization, 
translator determines the records to be unchanged (steps 
1203-1204). As described in the case of fast 
synchronization database, each record in the workspace 

25 has a hidden field called _Delta, which carries a single- 
letter value - 'D' for deleted, ^A' for added, and 
for changed. In the case of medium synchronization, the 
hidden field can contain four values, 'D' for deleted, 
^A' for added, *C' for changed, and 'U' for unchanged. 

30 Therefore, once the translator determines that the record 
is unchanged, the translator stores an appropriate value 
to indicate to the synchronizer that the record is 
unchanged (step 1205) . Records that are unchanged need 
not be loaded. A copy of the relevant data in the record 

35 is contained in the history file. Synchronizer 15 
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replicates the data of the unchanged record: using the 
content of the history file, in the same manner as in the 
case of fast synchronization databases. By relevant, we 
mean data in the fields that are synchronized- 
5 If a record is not unchanged, then the record has 

either been modified and added since the previous 
synchronization. The translator sets value of the hidden 
field as 'C which indicates to synchronizer 15 that the 
record was either added or changed (step 1206) . The 
10 translator then loads the changed or added record, from 
the database, field by field (steps 1207-1209) . The 
translator then loads the record into the workspace (step 
1211) . 

After the translator has loaded all the records in 

15 the database, there are in essence two logical lists in 
workspace 16. One is the list of records identified as 
changed/added since a previous synchronization- Second 
is the list of records identified as unchanged since a 
previous synchronization. Synchronizer 15 compares the 

20 unique IDs of the records in these two lists with the 

unique IDs in the history file (step 1213). (In the case 
of date range limited synchronization, the whole database 
would be loaded but only those records which are in the 
date range will be synchronized, as was the case for fast 

25 synchronization databases.) Based on the comparison, 
synchronizer 15 determines which records in the history 
file are no longer present in the database. Synchronizer 
15 determines that these records have been deleted and 
sets the hidden field value for these records as 'D' 

30 (step 1214), Synchronizer 15 processes these records in 
the same manner as when synchronizer 15 receives an 
indication from a fast synchronization database that a 
records has been deleted. The synchronizer also compares 
the unique IDs changed records to the unique IDs of the 

35 records of the history file (step 1215). The 
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Synchronizer determines that those unique IDs which are 
not present in the history file belong to newly added 
records (step 1216) • In that case, synchronizer 15 
changes the value stored in the hidden filed value to 'A' 
5 to indicate that the record was newly added. 

At this point the output of the medium 
synchronization database has been essentially transformed 
into output of a fast synchronization database. 
Synchronizer 15 then proceeds to synchronize the records 

10 in the same manner as synchronizer 15 does for fast 
synchronization databases, since the synchronizer has 
information as to which records have been changed/ added, 
deleted, and unchanged (step 1217). 

At the end of synchronization, during unloading, 

15 the history file is updated in the same manner as is the 
case for fast synchronization database, to ensure the 
history file records reflect the content of all records 
of the database at the end of synchronization (step 
1218)* During unloading, as in the case of fast 

20 synchronization, the translators wait for acknowledgement 
from the databases during unloading. 

Other embodiments are within the following claims. 
For example. Fig. 7 shows the pseudocode for 
another embodiment in which the medium synchronization 

25 database is able to perform answer queries based on 
specified criterion. An example of such a criterion 
would be "changed records after 1/1/1997" in response to 
which the database provides a list of records matching 
that criterion. The difference between this embodiment 

30 and the embodiment described in reference to Fig. 6 is as 
follows. The Translator, in step 1250, queries records 
that have date and time stamps that are prior to or at 
the same time as the date and time of the last 
synchronization. The Translator determines these records 

35 to be unchanged. The Translator also queries the 
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database for records that have date and time stamps that 
are subsequent to the date and time stamp of the last 
synchronization. Translator determines these records to 
be changed or added since the last synchronization. The 
5 rest of the processing by the Translator and synchronizer 
are the same as the embodiment described in reference to 
Fig. 6. 

In the case of those databases that provide Dirty 
bits instead of date and time stamps, the Translator 

10 determines which records have their Dirty bits set. 

Those that have their Dirty bit set are changed or added 
records while those that do not have their Dirty bits set 
are unchanged records. The rest of the processing by the 
Translator and synchronizer are the same as the 

15 embodiment described in reference to Fig. 6. 

Fig. 8 shows another embodiment for synchronizing 
a medixm synchronization database. In this case, for 
each record (step 1350) , the translator loads the unique 
ID and the date and time stamp or Dirty bit/ as may be 

20 the case. If the record has not been modified or added 
since the previous synchronization (step 1353) , the 
translator calls a special function (PutUnchangedRecord) 
of synchronizer 15 and also supplies the unique ID of the 
unchanged record to the synchronizer (step 1354) . In 

25 response to the function call, synchronizer 15 searches 
the history file for the supplied unique ID (step 1355) 
and clones the matching history file record (step 1356) . 

If the record has been modified or added since the 
previous synchronization (step 1357) , the record is 

30 loaded from the database (step 1358-1360) and loaded into 
the workspace (step 1361). Synchronization then proceeds 
as if the records of a regular database (i.e. a database 
that does not provide information that may be used to 
keep track of whether records of the database have been 

35 changed, added or deleted) are loaded, as described 
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briefly above and in more detail in '490, '"926, and '645 
applications. The deleted records, in this embodiment, 
are then determined as the two databases are 
synchronized. 

5 In the above described embodiments, a database 

provides database generated data that may be used to keep 
track of status of the record (e.g. changed, added, 
modified, deleted) . However, it is also possible to 
provide a program, for example running on a remote 

10 computer, that keeps track of the status of the records 
of a database* That remote program may then provide the 
synchronization program only those records that have been 
changed or added and use data less than the full record 
to identify those records that are unchanged or have been 

15 deleted. We will briefly describe an embodiment of such 
a program, which is described in detail in the commonly 
assigned copending U^S, patent application, incorporated 
herein in its entirety by reference, entitled 
"DISTRIBUTED SYNCHRONIZATION OF DATABASES", filed on 

20 September 11, 1997, serial no. 08/927,922. 

Briefly, referring to Figs. 9 and 10, a 
synchronization program , according to the embodiments 
described here, has a host segment 28 and a remote 
segment 26 which run on a host computer 20 and a remote 

25 computer 22, respectively. The two computer are 

connected together via a data transfer link 24 enabling 
them to transfer data between them. Data transfer link 
24 may be a slow data transfer link such as a serial 
infrared links, serial cables, modems and telephone 

30 lines, or other such data transfer links. A host 

database 13 and a remote database 14, e.g. scheduling 
databases, are stored on remote computer 22 and host 
computer 20, respectively. 

Generally, in some instances, both computers on 

35 which the two databases run are capable of running 
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programs other than a database, as in the case of, for 
example, general purpose computers such as desktop and 
notebook computers, or handheld computers having 
sufficient memory and processing power. In such a case, 
5 the synchronization program may be distributed between 
the two computers so as to, for example, increase the 
efficiency of using of a slow data transfer link between 
the two machines. 

Briefly, at remote computer 22, remote segment 26 

10 of the synchronization program loads records of remote 
database 13. Remote segment 26 then determines which 
records of the remote database have been changed/ added, 
deleted or left unchanged since a previous 
synchronization. If the remote database assigns unique 

15 identification codes (i»e. unique ID) to its records, 
remote segment 26 can further differentiate between 
records than have been added and those than have been 
changed since the previous synchronization. Remote 
segment 26 uses a remote history file 30 which stores 

20 data representing or reflecting the records of the 
database at the completion of the previous 
synchronization. This data may be a copy of remote 
database 13. It may also be hash numbers for each of the 
records of the remote database. If the remote database 

25 assigns unique IDs, the remote history file may contain 
those unique IDs together with the hash ntombers of the 
records corresponding to the stored unique IDs. 

Remote segment 26 sends those records of the 
remote database that have been changed or added to the 

30 host segment or the host computer. However, the remote 
segment does not send the unchanged or deleted records to 
the host computer. Instead, the remote segment sends a 
flag indicating the status of the record (e.g. unchanged 
or changed) and some data or information that uniquely 

35 identifies the record to the host segment. This data or 
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information may be a hash number of all or selected 
fields in the record at the completion of the last 
synchronization. It may also be the unique ID assigned 
to the record by the remote database, if the database 
5 assigns one to its records. 

Host segment 28 uses the received information or 
data that uniquely identifies the unchanged record to 
access a record in host history file 19 that corresponds 
to the received information or data. This record 

10 contains a copy of the data of the remote database record 
that the remote segment found to have been unchanged. 
Host segment 19 then uses this record to synchronize the 
databases by comparing it to the records of host database 
14. After synchronization, the remote and host history 

15 files and the databases are updated. Since the unchanged 
records which typically constitute most of the records of 
a database are not transferred to the host computer, a 
data transfer link, specially a slow data transfer link, 
is used with increased efficiency. 

20 We will describe two embodiments of a distributed 

synchronization program. We will first describe in 
general terms the overall structure of the distributed 
synchronization program in reference to Figs. 10 and 2 
which is common to both embodiments. We will then 

25 describe then the first and second embodiments performing 
a distributed synchronization in reference to Fig. 11-15. 



Fig. 10 shows the relationship between the various 
modules of an embodiment of a distributed synchronization 
program. Translation Engine 1 comprises a Control Module 
30 2 that is responsible for controlling the synchronizing 
process by instructing various modules to perform 
specif ic tasks on the records of the two databases being 
synchronized. The Control Module 2 also provides data 
that affects the specific operation of the various 
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components of the synchronization program, such as the 
name of the databases being synchronized and user 
preferences. Fig. 11 is the pseudocode of the steps 
taken by this module. The Synchronizer 15 has primary 
5 responsibility for carrying out the core synchronizing 
functions. It is a table-driven code which is capable of 
synchronizing various typeset databases whose 
characteristics are provided by control module 2 . The 
Synchronizer creates and uses a host workspace 16 (shown 

10 in detail in Fig, 2) , which is a temporary data array 
used during the synchronization process. 

A host translator 9 includes two modules: a 
reader module 10 which reads the data from the host 
database 14 and an unloader module 10 which analyzes and 

15 unloads records from the host workspace into the host 
database 14. Remote segment 26 also has similar modules 
for reading and unloading data from the remote database- 
The remote segment is designed specifically for 
interacting with remote database 13. The design of the 

20 remote segment is specifically based on the record and 
field structure of the remote database and remote 
database's Application Program Interface (API) 
requirements and limitations and other characteristics of 
the remote database. Similarly host translator 9 is 

25 designed specifically for the host database. The remote 
segment and host translator are not able to interact with 
any other databases or Applications. They are only aware 
of the characteristics of the databases for which they 
have been designed. In an alternate embodiment, the host 

30 translator and the remote segment can be designed as a 
table-driven code, where a general Translator is able to 
interact with a variety of databases based on the 
parameters supplied by, for example, the Control Module 
2. It should be noted that the remote segment and host 
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translator may be designed in various ways and still 
perforin the tasks set out in this embodiment. 

Fig. 11 is the pseudocode for the operation of 
Control Module 2 of the Translation Engine 1. We will 
5 use this pseudocode to generally describe distributed 
synchronization according to the invention. Control 
Module 2 first initializes itself and specifies the 
current user options to various modules (Step 401) . In 
step 402, control module 2 instructs the Synchronizer to 

10 load host history file 19. Synchronizer 15 in response 
creates host workspace 16 data array and loads host 
history file 19 into host workspace 16. Host history 
file 19 is a file that was saved at the end of last 
synchronization and contains records representative of 

15 the records of the two databases at the end of the 

previous synchronization. Typically, the host history 
file contains a copy of the results of the previous 
synchronization of the synchronized records of the two 
databases. It should be noted that the content of the 

20 records of the history file may be limited only to those 
fields that are synchronized and the data may be 
translated and stored in a format different than that of 
the remote database or the host database. This data can 
be used to reconstruct the content of the records of the 

25 remote database as they were at the end of the previous 
synchronization. The host history file is generally used 
to determine changes to the databases since a previous 
synchronization and also to recreate records not sent 
from the remote segment, as will be described in detail 

30 below. If no history file from a previous 

synchronization exists or the user chooses to synchronize 
without using the history file, in step 402 the 
synchronizer does not load a history file. In that case, 
all the records from both databases will be loaded into 

35 the host workspace. We will describe the rest of the 
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operation of the control module as if a history file 
exists and will be used. 

Once the History File is loaded into the host 
workspace. Control Module 2 instructs host translator 13 
5 to load the host database records (step 403), Host 
Reader module 11 of the host Translator reads the host 
database records and sends them to the Synchronizer for 
writing into the host workspace. 

Control Module 2 then instructs remote segment to 

10 send the records of the remote database (step 404)- 

Remote segment 26 reads the remote database records and 
sends them to Synchronizer 15 for writing into the host 
workspace. The actions taken by the synchronizer and 
the remote segment in response to step 404 will be 

15 described in detail in reference to Figs. 12-15, below. 

Records in the host workspace are stored according 
to either the host database or the remote database data 
structures. Therefore, as synchronizer 15 receives each 
record, the Synchronizer maps that record using the 

20 appropriate record map (i.e. either a remote database to 
host database record map or a host database to remote 
database record map) before writing the record into the 
next available spot in the host workspace* Mapping may 
be performed by other modules, e.g. the remote segment. 

25 The records may also be "translated", i,e* cast into a 
format which synchronizer can use (a "translation" method 
is described in the '390 patent) . For example, a date 
stored as "April 1, 97" may be translated into a format 
preferred by the synchronizer, e.g. "4-1-97". 

30 control module 2 then instructs the Synchronizer 

to perform a Conflict Analysis and Resolution ("CAAR") 
procedure on the records in the host workspace (step 
405), which procedure is described in detail in the 
following applications of the assignee hereof. Puma 

35 Technology, Inc. of St. Jose, California, incorporated by 
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reference in their entirety including any appendices: 
"Synchronization of Recurring Records in Incompatible 
Databases", Serial no* 08/752,490, filed on November 13, 
1996 (hereinafter, "M90 application"); "Synchronization 
5 of Databases with Record Sanitizing and Intelligent 
Comparison," Serial no* 08/749,926, filed November 13, 
1996 (hereinafter, "'926 application"); "Synchronization 
of Databases with Date Range," Serial no, 08/748,645, 
filed November 13/ 1996 (hereinafter, "'645 

10 application") . Generally, synchronization is a process 
of analyzing records from the remote database and host 
database against the records of the history file to 
determine the changes, additions, and deletions in each 
of the two databases since the previous synchronization 

15 and what additions, deletions, or updates need be made to 
the databases to synchronize the records of the 
databases/ Briefly, during CAAR, the synchronization 
engine (i^e. the Synchronizer) compares the records in 
the host workspace and determines what synchronizing 

20 actions should be taken. The synchronization engine 
processes the records, including comparing them to one 
another, in order to form them into groups of related 
records. Each of these groups may comprise at most one 
recurring or a group of related nonrecurring records from 

25 each of the databases and history file. After forming 
these groups from all records of the two databases, the 
Synchronizer determines what synchronization action 
should be taken. To do this, the Synchronizer compares 
them, determines their differences, and decides what 

30 synchronization action is appropriate or asks the user 
what action should be taken. The synchronizer then 
associates with that record, the specific "action" (e.g. 
add, update or delete) that must be taken with respect to 
that record in that record's database. During "CAAR", 

35 the user may select not to synchronize a particular 
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record with the other database. We will describe below 
in detail the steps performed by the synchronizer and the 
remote segment in response to the output of CAAR as the 
output relates to the remote database - 
5 Once Synchronizer 15 finishes performing CAAR on 

the records, the records may be unloaded or written into 
their respective databases, including any additions, 
updates, or deletions. However, prior to doing so, the 
user is asked to confirm proceeding with unloading (steps 

10 108-109) . Up to this point, neither the databases nor 
the History File have been modified. The user may obtain 
through the Control Module's Graphical User Interface 
(GUI) various information regarding what will transpire 
upon unloading* 

15 If the user chooses to proceed with 

synchronization and to unload, the records are then 
unloaded in order into the host database, the remote 
database and the History File. The Synchronizer in 
conjunction with the host translator and the remote 

20 segment perform the unloading for the databases. 

Synchronizer 15 creates a host history File and unloads 
the records into it. Control Module 2 first instructs 
the host translator to unload the records from host 
workspace into the host database. Following unloading of 

25 the host records. Control Module 2 instructs the 

synchronizer and the remote segment to unload the remote 
records from the host workspace (step 409) . We will 
describe in detail below, in reference to Figs* 12-15, 
the specific actions taken by Synchronizer 15 and remote 

30 segment 26 in order to unload data from the host 

workspace into the remote database and the update remote 
history file 28, Control Module 2 next instructs the 
Synchronizer to create a new History File (step 112) . At 
this point Synchronization is complete. 
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Referring to Figs. 12-15, we will now describe the 
actions taken by the remote segment in coordination with 
the Synchronizer in response to the instructions from 
control module 2 in step 404 to load records of the 
5 remote database and in step 409 to unload the records of 
the remote database from the host workspace. 
Specifically, we will describe two embodiments. In the 
case of the first embodiment, the remote database assigns 
unique identification codes (i.e* unique IDs) to each of 

10 its records as they are created. In the case of the 
second embodiment, the remote database does not assign 
unique IDs to its records. Fig. 12 is the pseudocode for 
the steps taken by the remote segment while Fig. 13 is 
the pseudocode for the steps taken by the Synchronizer in 

15 the case of the second embodiment. Similarly, Fig. 14 is 
the pseudocode for the steps taken by the remote segment 
while Fig. 15 is the pseudocode for the steps taken by 
the Synchronizer in the case of the first embodiment. 
Briefly, the remote segment determines which 

20 records have been changed /added, deleted or left 

unchanged since a previous synchronization. The remote 
segment uses a history file located on the remote 
computer ("remote history file") to determine which 
records may have been changed/ added, deleted or left 

25 unchanged since a previous synchronization- The remote 
segment essentially can translate outputs of any database 
into outputs of a fast synchronization database which is 
a type of database that generally supplies information as 
to which of its records have been changed, added, 

30 deleted, or left unchanged. Fast synchronization 

databases and an example of a method of synchronizing 
them with other databases is described in detail in the 
M90, '926 & '645 applications. Therefore, for example, 
this method of distributed synchronization may also be 
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implemented with any synchronization program that is able 
to synchronize such databases. 

Generally, the remote segment sends the host 
segment, over the data transfer link, only the content of 
5 those records that have been changed or newly added. As 
for unchanged records, the history file contains all 
necessary information to recreate or synchronize those 
records, if needed. Therefore, it is not necessary to 
transfer those records to the host segment • Only some 

10 data or identification code that uniquely identifies the 
record to the synchronizer need be transferred for such a 
record. Since the majority of records are typically 
unchanged records, not transferring them over the slow 
data transfer link improves the efficiency of the 

15 synchronization process. 

After all necessary information has been 
transferred to the host segment, the Synchronizer 
synchronizes the databases. Following synchronization, 
the host segment transfers information necessary to 

2 0 update the remote database and the remote history file to 
the remote segment . The remote segment then updates its 
history file and the remote database. 

Since both the host and remote segments rely 
heavily on history files to enable distributed 

25 synchronization, it is important that the host and remote 
segments use history files that correspond to one 
another, i.e. both contain records corresponding to a 
previous synchronization of the same two databases. In 
the described embodiment, the remote and host history 

30 files are named using a common naming convention. The 
name of a file is made up of six components: 

1) Name or ID of the host computer, which may be 
an assigned name such as an assigned GUID in the case of 
operating systems by Microsoft Corporation of Redmond, 
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Washington, or UUID in the case of operating systems by 
Open Software Foundation; 

2) Name or ID of the host database application, 
e.g. trademark designations "Lotus Organizer" or 

5 "Microsoft Schedule+"; 

3) Name or ID of the host database file as 
stored on the long term storage (e.g. hard disk drive) of 
the host computer, e,g* "My Calendar"; 

4) Name or ID of the remote computer; 
10 5) Name or ID of the remote database 

application; and 

6) Name or ID of the remote database. 
Therefore , the remote segment and the host segment ensure 
that the host history file have the same name. Moreover, 

15 each of the history files have the date and time stamp of 
the previous synchronization. The remote segment and 
synchronizer use this to ensure that the history files 
from the same previous synchronization of the two 
databases are used. 

20 Having described in general terms the actions 

taken by the remote segment in coordination with the 
Synchronizer in response to the instructions from control 
module 2 in steps 404 and 409 (Fig. 11) , we will now 
describe in detail a first embodiment of their operation 

25 for the case where the remote database assigns unique IDs 
to its records. We will do so in reference to Figs. 12 
and 13. 

Fig. 12 is the pseudocode for steps taken by the 
remote segment in response to the instruction by control 

30 module in step 404 to load the remote database records 
into the host workspace (Fig. 11). The remote segment 
first initializes (i.e. creates) a remote workspace in 
the remote computer (step 501). The remote segment then 
compares the name of the host history file with the name 

35 of any remote history file in the remote computer. If 
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the remote segment finds a remote history file that 
matches the host history file (i.e. a remote history file 
that matches the host history file) (step 502), then the 
remote segment examine the date and time stamp of the 
5 host and remote history files. If the date and time 
stamp in the remote history file matches the one in the 
host history file (step 503), then the remote segment 
determines that two history files correspond to one 
another- Hence, the remote segment loads the remote 

10 history file into the remote workspace. 

In general, if matching history files do not exist 
on the remote and host computers, the remote segment 
transfers all remote database records to the host 
computer. Therefore, if the name of the host and remote 

15 history files match but the date and time stamps do not 
match (step 505) , then the remote segment assumes that 
remote history file is not the correct remote history 
file to be used. The remote segment removes that history 
file (step 506) and transfers all remote database records 

20 to the host computer (step 507). If no remote history 
file matches the host history file (step 508) , then the 
remote segment assumes an appropriate remote history file 
does not exist. The remote segment transfers all the 
records to the host computer (step 509) . To transfer all 

25 the records in the above steps, the remote segment first 
loads and stores all records of the remote database in 
the remote workspace. The remote segment then transfers 
all records in the remote database to the host segment. 
If remote segment transfers all the records of the remote 

30 database to the host segment in either step 504 or 509, 
then the remote will go to step 528. It should be noted 
that the host segment will use the host history file, if 
one exists, to perform the synchronization. 

If an appropriate remote history file exists - 

35 i.e. conditions of steps 501 and 504 are satisfied - the 



DOCID: <WO 9821648A1_L> 



wo 98/21648 



PCT/US97/20627 



remote history file is loaded into the work~ space- It is 
then used to "filter" out information that need not be 
sent to the host segment since it already exists on the 
host segment. Generally, the history files on the remote 
5 and history files are used to store information 

representative of the remote database at the end of the 
previous synchronization* The records of the remote 
history file in the first embodiment contain the unique 
ID of the records and hash numbers of those records at 
10 the completion of a prior synchronization. In other 

embodiments, the remote history file may contain some or 
all of the field values of the records of the remote 
database . 

Hashing may be described as converting any data, 

15 such as a string of characters, into a more compacted 
format, such as a number, meant to represent that string 
of characters. It may be considered to be a content- 
based encoding technique • The hashed values may be used 
as a surrogate for a hashed string of characters, for 

20 example, to compare strings. An example of a hashing 
algorithm is to calculate the following sum for every 
characters in a character string: 

sum ^ character + (31 * sum) , 
where character is the number stored ^ in the memory to 

25 represent that character (e.g. an Ascii value). (It 
should be noted that there are many ways of hashing 
data.) At the end of the computation, sum contains the 
hash number for that string of characters. In the 
described embodiments, the hash number is a 32 bit number 

30 and therefore can have a value between 2^^ different 
values. Because the expected number of records is much 
less than this number, the probability of two different 
records having the same hash value is small. Therefore, 
hash nxmbers can be used to perform comparisons instead 

35 of comparing the non-hashed data or a preliminary check 
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before comparing the data, with relatively low risk 
inaccurate comparison. We have also use hash numbers as 
a unique identification code, which will be described in 
the second embodiment, 
5 The remote segment uses the remote history file to 

determine whether a record has been changed, deleted, or 
added since a previous synchronization. Therefore, for 
records that are unchanged, which typically constitute 
the majority of records in a database, the remote segment 

10 sends information that the host segment can use to 

identify the matching records in the host history file. 
That matching history file record contains the same data 
as necessary to use for synchronization as that on the 
remote database since the record is unchanged* 

15 Therefore, there is no need to send the whole record. In 
essence, the remote segment uses the remote history file 
to filter out information that is already contained in 
the host history file and sending only those records that 
have been changed or added. In some embodiments, the 

20 remote history file may contain all the, field values of 
the records of the remote database. In those 
embodiments , the remote segment can determine not only 
which records have been changed but more specifically 
which field values have been changed. In that case, the 

25 remote segment can determine and then, send only those 
field values that have been changed, further increasing 
the efficiency of using the slow data transfer link. 

We will now describe this process in detail. In 
the described embodiment, for each record of the remote 

30 database (step 515), the remote segment loads the field 
values, including the unique ID, of the record into the 
remote workspace (step 512). As the records are loaded, 
they are translated (e.g. "translated" as described in 
the '390 patent) into a universal format for the remote 

35 workspace. The records will be translated back into the 
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format of the remote database as they are written into 
the remote database. The remote segment also computes a 
hash niunber based on all or selected (e.g. the fields to 
be synchronized) field values (step 513) . In the 
5 described embodiment, the hashing number is a 32 bit 
number. The fields on which the hash number is based on 
remain the same for all synchronizations relying on this 
remote history file. The host segment also performs a 
hash on the same fields. If the fields which are hashed 

10 changes, the hash number of unchanged records would not 
remain the same from one synchronization to the next. 

If the unique ID matches one of the unique IDs of 
records in the remote history file (step 515) , then the 
record was present during the previous synchronization. 

15 That record could either be a changed record or an 

unchanged record. If the computed hash number for the 
record matches the hash number of the record in the 
history file (step 516) , then the remote segment assiunes 
that the record has not been changed since the previous 

20 synchronization and therefore can be created by the host 
segment from the host history file. The remote segment 
will take no action (step 517). In other embodiments, 
the remote segment can send the unique ID and a flag 
indicating that the record is unchanged to the host 

25 segment. 

If the computed hash number does not match that of 
the history file record (step 518), the remote segment 
assumes that the record has been changed since a previous 
synchronization. Therefore, the remote segment sends the 

30 host computer the field values including the unique ID 
and a ** changed" flag (step 519). In some embodiments, 
only those field values that have been changed since the 
previous synchronization will be sent, as described 
above. The remote segment then creates a new entry for 

35 the changed record in the history file (step 520) and 
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marks the record as unacknowledged (step 521) , the 
purpose and function of which we will now briefly 
describe and is also described in the '490, '926 and '645 
applications. 

5 Generally, the remote segment does not change an 

entry in the remote history file, until it receives an 
instruction indicating that the host segment has 
synchronized and updated the host database with that 
record. This is done so that if for any reason (e.g. 

10 user does not want to update that record of the host 
database as described above) the host database is not 
synchronized with that record, the remote segment will 
not treat that record as unchanged during the next 
synchronization. The acknowledgement may take the form 

15 of an "acknowledgment" flag or an "action" instruction 
which instructs the ramote segment to add, update, or 
delete that record of the remote database, as described 
above. Therefore, for each changed and deleted record, 
the remote segment creates a new entry and marks the 

20 entry as "unacknowledged". If an "acknowledgment" flag 
is received, the old history file record is deleted. If 
an "acknowledgement" flag is not received, the new 
workspace entry is deleted. The steps will be described 
further below. 

25 If in step 515 the remote segment determines that 

the unique ID of the loaded record does not match any of 
the unique IDs stored in the records of the history file 
(step 521) , the remote segment assumes that the record 
loaded from the remote database has been newly added. 

30 Therefore, the remote segment sends the host segment a 
copy of the field values of those fields of the record to 
be synchronized (which may be all or less than all the 
fields) together with an "added" flag (step 524). , As in 
the case of a changed record, the remote segment creates 

35 a new remote workspace entry and enters the unique ID and 
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hash value of the record (step 525) , The naw entry is 
marked as unacknowledged (step 526) . 

After all the records have been loaded (step 528) , 
the remote database determines that unique IDs in the 
5 history file that have not been matched represent the 
deleted records (step 529) . Therefore, the remote 
segment sends the host segment those unique IDS together 
with "delete" flags (step 530). 

After the remote segment has finished providing 

10 data to the host segment, the host segment synchronizes 
the two databases based on the input from the remote 
segment. The remote segment waits until the host segment 
finishes synchronizing and instructs the remote segment 
in step 409 in Fig. 11 to begin unloading into the remote 

15 database (step 532) . 

The host segment synchronizes the two database 
similar in the way it synchronizes a so-called " fast 
synchronization" database (as defined in the M90, '926, 
and '645 applications) with another database. The 

20 operation of a synchronization program synchronizing a 
fast synchronization database with either a fast 
synchronization database or a regular database ( i . e . non- 
fast synchronization) is described in detail in the M90, 
'926, and '645- We will now describe in detail how the 

25 information from the remote segment is used to 

synchronize the remote database with another database. 

As described above, a remote segment sending 
remote database records to the Synchronizer provides 
field values of only those records which have been 

30 changed or added since the previous synchronization but 
not those records that are unchanged or deleted. 
Therefore, unlike a regular database Translator, the 
remote segment does not provide the Synchronizer with 
unchanged records . 
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In order to synchronize the remote database with 
the host database, the Synchronizer transforms 
information from the remote segment into regarding 
unchanged records into equivalent regular database 
5 records. These transformed records are then used by the 
Synchronizer in the synchronization. Essentially, the 
synchronizer transforms and uses the information sent by 
the remote segment to identify a record in the history 
file that is a copy of the field values of the unchanged 

10 remote database record. In the described embodiment, the 
synchronizer also copies that history file record and 
flags as being the remote database record. 

The described embodiment uses the host history 
file to perform this transformation. At the beginning of 

15 a first synchronization between the two databases, all 
records in the remote database are loaded into the host 
history file. As changes, additions, and deletions are 
made to the remote database, during each subsequent 
synchronization, the same changes, additions, and 

20 deletions are made to the host history file. Therefore, 
the host history file at the end of each synchronization 
will contain a copy of the relevant content of the remote 
database after synchronization. By relevant, we mean 
data in the fields that are synchronized. For example, 

25 it may be the case that the host history file contain 
data in fields that are not synchronized. Moreover, if 
the records of the remote are mapped or recast into 
another format (e.g. "translated" as described in the 
'390 patent) the records of the history file contain a 

30 copy of the records of the database, as mapped, 

translated, or both. The Synchronizer uses the mapped or 
translated records for synchronization. Therefore, it 
only needs the mapped or translated copy of the unchanged 
record. In other embodiments, the host history file may 

35 contains copies of all the records exactly as they are in 
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the remote database or in some other format- that is 
useful for the particular application. 

Referring to Fig« 13, in the described embodiment, 
all records received by the host segment from the remote 
5 segment are flagged with one of Added, Changed, or 

Deleted flags. For all records received from the remote 
segment (step 601), the host synchronizer performs the 
following functions- If a received record is flagged as 
an added record (step 602), then the received record is 

10 added to the host workspace (step 603) . Since the record 
is new, it is not associated or linked to any history 
file record. If a record is flagged as a "changed" 
record (step 604), then the Synchronizer uses the 
received unique ID to find the corresponding record in 

15 the history file (step 605) and links the received remote 
record to that history file record (step 606) . If the 
received record is flagged as a "deleted" record (step 
607), then the Synchronizer uses the received unique ID 
to find the corresponding record in the history file 

20 (step 608) and marks the history file record as deleted 
(step 609) , 

After all the received records are analyzed (step 
611) , if any host history file records containing remote 
database unique IDs are left that were not matched 

25 against the received records, the synchronizer assumes 
that those records represent the remote database records 
that are unchanged. For all those records (step 612), 
the synchronizer clones the host history file record 
(i,e. create a workspace entry and copy all the host 

30 history file record in to that entry) and treats it as a 
record received from the remote database. At this point 
the host segment proceeds with synchronization since the 
records of the remote database have now been loaded. In 
essence, referring back to Fig. 11, this is the end of 

35 Step 404. 
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As previously described, after the synchronizer 
has performed CAAR, the user must confirm to proceed with 
updating the remote database (step 406 in Fig. 11) . If 
the user decides to terminate the synchronization, 
5 changes are not made to the host history file or the 
databases. In the case of the remote database, as 
described in reference to Fig. 12, the remote segment is 
waiting for the synchronizer to finish synchronizing. If 
the user aborts synchronization (step 533) , the remote 

10 segment discards the remote workspace (step 534) , saves 
the original history file without any changes (step 535) , 
and terminates the process at the remote computer. 

If the user confirms to proceed with updating the 
database (step 406 in Fig. 11) , control module 2 

15 instructs the synchronizer and the remote segment to 
proceed with unloading the records from the workspace 
into the remote database. As stated, at this point, the 
remote segment is waiting for the synchronizer to finish 
synchronizing (step 532 in Fig. 12). During the 

20 synchronization, the synchronizer has determined what 
"actions" with respect to which record in which database 
should be taken (update, delete, or add) to complete 
synchronization. If changes or additions are made to the 
host database in the case of particular record but no 

25 action need be taken with respect to that record in the 
remote database, the synchronizer deteirmines that an 
"acknowledgement" should be sent to the remote segment. 
The synchronizer sends all the actions concerning the 
remote database together with the associated record to 

30 the remote (step 616) . The synchronizer then sends the 
unique ID of those records that require 

"acknowledgements" to be sent to the remote together with 
an appropriate flag (step 617). 

Referring again to Fig. 12, for each action item 
35 or acknowledgement received at the remote segment (step 
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538), the following steps are performed. T-f the received 
data indicates an "acknowledgement" or "action" with 
respect to a record that was added or changed since the 
previous synchronization, the remote segment marks the 
5 new workspace entry that was created in either step 520 
or step 525 as acknowledged (step 540). The remote 
segment also discards or removes any other entry in the 
workspace that contains the unique ID of this record, 
which is typically the entry that was loaded from the 

10 remote history file. Therefore, as previously described, 
this entry as opposed to the old remote history file 
entry associated with this record will be written into 
the history file at the end of the process at the remote 
segment. This in essence updates the history file, as 

15 will be described below. 

If the received data indicates an action item that 
tells the remote segment to update, change, or add a 
remote database record (step 543) , the remote segment 
performs that action with respect to the remote database. 

20 The remote segment also performs the same steps as steps 
540 and 541 (step 544 and 545) . If a new record was 
added to the database (step 546) , it will be assigned a 
new unique ID. The remote segment sends that unique ID 
to the host segment (step 547) - The host segment 

25 includes that unique ID in the host work space in 
association with that record (step 618 in Fig. 13). 

After all the records have been received, the 
remote segment discards all unacknowledged entries from 
the workspace. Therefore, in the case of those added or 

30 changed records with which the user decided not to update 
the host database, the remote history file remains 
unchanged. The remote history file is then updated from 
the remote workspace. At this point the control module 
continues with step 410 in Fig. 11, i.e. creating the 
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history file to end the synchronization of the two 
databases , 

In the first embodiment, which we described above, 
the remote database assigns unique IDs to its records* 
5 We will now describe a second embodiment for the case 
where the remote database does not assign unique IDs to 
its records. In such a case, the remote segment provides 
some information less than all the fields of the records 
to uniquely identify an unchanged record to the host 

10 segment. This information may be a hash value. The host 
segment uses this information to find and then use the 
host history file copy of the unchanged remote database 
record to synchronize the two databases. 

To identify a record from the previous 

15 synchronization or an unchanged record, the remote 
segment can use a content based code, that is a code 
whose value depends on the content of all or a selected 
number of the fields of a record. In the second 
embodiment, the remote segment uses hash numbers. Since 

20 in the case of an unchanged record, its content has 

remained the same, its hash number remains the same. The 
hash number acts as a unique identifier and therefore 
enables the remote and host segments to identify the 
unchanged record by its hash code. The hash code can be 

25 used to identify a record that is stored in the host 

history file, since its content remains the same from the 
end of one synchronization to the time it is updated. It 
may also be transmitted to Identify an unchanged record 
or an unchanged version of a changed record. A host 

3 0 history file record can in effect be identified using the 
hash code of that record. 

We will describe the operation of this embodiment 
in reference to Figs. 14 and 15. Steps 701 -711 are the 
same as steps 501-511 in Fig. 12, described above in 

35 reference to the first embodiment. These steps are 
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generally concerned with finding the correct remote 
history file. 

After determining that there is a suitable remote 
history file, for each record of the remote database 
5 (step 712), the following functions are performed. The 
remote segment loads and translates a record of the 
remote database into the remote workspace (step 713) and 
a hash number is calculated for that record (step 714) . 
If the hash number of the remote record matches one or 

10 more hash numbers in the remote history file (step 715) , 
then the remote segment assumes that the record has not 
been changed since a previous synchronization. 

It is possible that the hash number may be 
repeated more than once, e.g. because of duplicate 

15 records or records that appear as duplicates because some 
of their fields are not synchronized. Therefore, the 
remote segment sends additional information that can be 
used to identify which of the multiple identical hash 
numbers a particular record relates to. This is done 

20 because during updating the remote history file record at 
the end of synchronization, the same number of identical 
hash numbers as matching remote database records are 
updated. In the second embodiment, this additional 
information is the index number associated with each 

25 entry of the remote workspace. Therefore, when the hash 
number of the remote record matches one or more hash 
numbers in the remote history file (step 715) , the remote 
segment sends the hash number, a flag indicating that the 
record is unchanged, and the index nximber of that hash 

30 number to the host segment (step 716). Obviously if the 
index number was previously sent, the next index number 
for the identical hash is sent. 

If the hash number does not match one or more hash 
numbers in the history file (step 717), the remote 

35 segment treats that record as having been newly added. 
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Therefore, the remote segment sends the host segment a 
copy of the field values of the record, the remote 
workspace index number, and an "added" flag (step 720). 
The remote workspace index number makes it easier to 
5 perform future search of the remote workspace when data 
with respect to this record is received. As in the case 
of changed and added record in the first embodiment, the 
remote segment also creates a new remote workspace entry 
and enters hash number value of the record (step 718). 

10 The new entry is marked as "unacknowledged" (step 719) . 
It should be noted that although the remote segment 
treats the record as a new record, the remote segment can 
not distinguish between an added and a changed record. 
Therefore, the synchronizer during synchronization does 

15 not treat it as a new record. Instead, the synchronizer 
compares the record to determine whether it matches with 
any of host history file record which would mean it is a 
changed record . 

After reading all the remote database records and 

20 processing them (step 722), the remote segment removes 
from the remote workspace all entries that have hash 
numbers that are unmatched (step 723). These entries 
represent records that have either been changed or 
deleted since the previous synchronization. 

25 After the remote segment has finished providing 

data to the host segment, the host segment synchronizes 
the two databases based on the input from the remote 
segment. The remote segment waits until the host segment 
finishes synchronizing and instructs the remote segment 

30 in step 409 in Fig. 11 to begin unloading into the remote 
database ( step 724). 

Referring to Fig. 15, as in the case of the first 
embodiment, the synchronizer on the host computer uses 
the information to identify those records in the host 

35 history file that correspond to the unchanged remote 
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database records. For every record received from the 
remote segment that is flagged as added (step 801) , the 
synchronizer adds the record to the host workspace (step 
802) and during CAAR compares the record to the history 
5 file to determine whether the record is a changed or 
added record. . For every record received from the remote 
segment that is flagged as "unchanged" (step 804), in the 
same manner as the first embodiment, the synchronizer 
finds the corresponding host history file record by 

10 finding a record that has the same hash number as that 
sent by the remote synchronizer (step 805) . The 
synchronizer then clones the record (step 806), as 
previously described, and treats as if it is a record 
received from the remote database. At the end of this 

15 process, when all the records of the remote database are 
loaded into the host workspace, the control module 
proceeds to step 405 in Fig. 11 to begin CAAR. CT^AR will 
then analyze the records in the host workspace to 
determine which remote records were added, which were 

20 changed, and which were deleted since the previous 
i synchronization. 

After CAAR, if the user confirms to proceed with 
updating the database, control module 2 instructs the 
synchronizer and the remote segment to proceed with 

25 unloading the records from the workspace into the remote 
database (step 409 in Fig. 11). As stated, at this 
point, the remote segment is waiting for the synchronizer 
to finish synchronizing (step 724 in Fig. 14) . During 
performing CAAR, the synchronizer has determined what 

30 actions should be taken (update, delete, or add) to each 
database. If changes or additions are made to the host 
database in the case of a particular record but no action 
need be taken with respect to that record in the remote 
database, the synchronizer determines that at least an 

35 "acknowledgement" is to be sent to the remote segment. 
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The synchronizer sends all the actions concerning the 
remote database together with the associated record and 
remote workspace index to the remote (step 809) . The 
synchronizer then sends the remote workspace index of 
5 those records that require acknowledgements to be sent to 
the remote together with an appropriate flag (step 810). 
Therefore, the remote workspace index is used to identify 
which records in the remote workspace should be 
"acknowledged" . 

10 Referring back to Fig. 14, steps 725-729 are the 

same as steps 533-537, which were described in reference 
to the first embodiment. For each action item or 
acknowledgement received at the remote segment (step 
730) , the following steps are performed. If the data 

15 received indicates an "acknowledgement" or "action" with 
respect to a record that was sent to the host segment 
flagged as "added" (step 731), the remote segment marks 
the new workspace entry that was created in either step 
718 as acknowledged (step 732). It should be noted that 

20 the remote workspace index number is used to locate the 
remote workspace entry. Therefore, as previously 
described, this entry will be written into the history 
file at the end of the process at the remote segment. 

If the received data indicates an action item that 

25 tells the remote segment to update, change, or add a 
remote database record (step 733) , the remote segment 
performs that action with respect to the remote database. 
The remote segment also updates the remote workspace and 
marks the entry as "acknowledge" (step 735) . 

30 After all the records have been received, the 

remote segment discards all unacknowledged entries from 
the workspace, which were newly created entries which 
were not acknowledged. Therefore, in case of those added 
or changed records with the user decided not to update 

35 the host database with, the remote history file remains 
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unchanged. The remote history file is then- updated from 
the workspace. At this point the control module 
continues with step 410 in Fig. 11, i,e, creating the 
history file to end the synchronization of the two 
5 databases. 

Although we have described embodiments in which 
the host segment transforms the input from the remote 
segment, it should be noted that other embodiments of the 
host segment may not transform the input from the remote 

10 segment since they are designed to use inputs that 

informs them of which records have been changed, added 
and deleted or have been left unchanged. Other 
embodiments in which the host segment requires different 
types of input, the input from the remote segment are 

15 transformed as required. The various embodiments of the 
host segment may or may not use a history file. 

Other embodiments are within the following claims. 
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What is claimed is: 

1- A computer implemented method of 
synchronizing a first and a second database comprising: 

determining whether the records of the first 
database have been changed or added since the previous 
synchronization, based on data reflecting whether the 
records of the first database have been added or changed 
since a previous synchronization; 

if one of the records of the first database has 
not been changed or added since the previous 
synchronization, performing a synchronization with 
records of the second database using a record 
representative of the one record at the time of a 
previous synchronization, the representative record being 
stored in a history file containing records reflecting 
the contents of records of the databases at the time of a 
previous synchronization • 

2. The computer implemented method of claim 1, 
wherein the data comprises database generated data for 

20 keeping track of whether the records of the first 
database have been added or changed since a previous 
synchr oni zat ion . 

3 . The computer implemented method of claim 2 
wherein the computer generated data indicates the most 

25 recent date and time of when the records were created or 
changed • 

4 . The computer implemented method of claim 2 
wherein the computer generated data comprises a flag set 
when the records are created or changed. 



10 
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5. The computer implemented method -of claim 2 
wherein the first database provides further database 
generated data indicating which of the records were 
deleted since the previous synchronization, further 

5 comprising: 

identifying records of the history file 
corresponding to the deleted records by performing a 
comparison of the further computer generated data with 
the history file; and 
10 completing the synchronization using a result of 

the identification. 

6. The computer implemented method of claim 2 
further comprising: 

identifying records of the history file 
15 corresponding to records of the first database deleted 
since the previous synchronization by performing a 
comparison of the records of the history file and a 
result of determining whether the records of the first 
database have been added or changed* 

20 7* The computer implemented method of claim 2 

wherein the first database assigns a unique 
identification data to the records of the first database, 
the method further comprising: 

performing a comparison of the records of the 

25 history file and the unique identification data of 

records in the first database that have been changed or 
added since the previous synchronization; and 

completing synchronization using a result of the 
comparison. 
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8 . The computer implemented method of claim 2 
further comprising: 

modifying, adding, or deleting the records of the 
first database based on a result of the synchronization. 

5 9, The computer implemented method of claim 2 

further comprising modifying, adding, or deleting records 
in the history file using results of the synchronization 
such that the history file contains records reflecting 
the contents of records of the databases after the 
10 synchronization . 

10. A computer program, resident on a computer 
readable medium, for synchronizing a first and a second 
database, comprising instructions for: 

determining whether the records of the first 
15 database have been changed or added since the previous 
synchronization, based on data reflecting whether the 
records of the first database have been added or changed 
since a previous synchronization; 

if one of the records of the first database has 
2 0 not been changed or added since the previous 

synchronization, performing a synchronization with 
records of the second database using a record 
representative of the one record at the time of a 
previous synchronization, the representative record being 
25 stored in a history file containing records reflecting 
the contents of records of the databases at the time of a 
previous synchronization. 

11. The computer program of claim 10, wherein the 
data comprises database generated data for keeping track 

30 of whether the records of the first database have been 
added or changed since a previous synchronization. 
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12 . The computer program of claim 11 wherein the 
computer generated data indicates the most recent date 
and time of when the records were created or changed • 

13. The computer program of claim 11 wherein the 
5 computer generated data comprises a flag set when the 

recorda are created or changed. 

14. The computer program of claim 11 wherein the 
first database provides further database generated data 
indicating which of the records were deleted since the 

10 previous synchronization, further comprising instructions 
for: 

identifying records of the history file 
corresponding to the deleted records by performing a 
comparison of the further computer generated data with 
15 the history file; and 

completing the synchronization using a result of 
the identification. 

15. The computer program of claim 11 further 
comprising instructions for: 

20 identifying records of the history file 

corresponding to records of the first database deleted 
since the previous synchronization by performing a 
comparison of the records of the history file and a 
result of determining whether the records of the first 

25 database have been added or changed. 
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16 • The computer program of claim 11 wherein the 
first database assigns a unique identification data to 
the records of the first database, the computer program 
further comprising instructions for: 
5 performing a comparison of the records of the 

history file and the unique identification data of 
records in the first database that have been changed or 
added since the previous synchronization; and 

completing synchronization using a result of the 
10 comparison. 

17. The computer program of claim 11 further 
comprising instructions for: 

modifying, adding, or deleting records of the 
first database based on a result of the synchronization. 

15 18. The computer program of claim 11 further 

comprising instructions for modifying, adding, or 
deleting records in the history file using results of the 
synchronization such that the history file contains 
records reflecting the contents of records of the 

20 databases after the synchronization. 
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19. A computer implemented method for 
synchronizing a first database located on a first 
computer and a second database located on a second 
computer, the method comprising: 
5 determining whether a record of the first database 

has been changed or added since a previous 
synchronization ; 

if the record of the first database has not been 
changed or added since the previous synchronization, 

10 sending from the first computer to the second computer 
information which the second computer uses to identify 
the record of the first database to be unchanged, wherein 
a history file located on the second computer contains 
records reflecting the content of records of the first 

15 database at the completion of a previous synchronization 
and said information identifies a record in the history 
file reflecting the content of the record of the first 
database; and 

synchronizing the first database and the second 

20 database using the sent information. 
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20, A computer program, resident otv a computer 
readable medium for synchronizing a first database 
located on a first computer and a second database located 
on a second computer, comprising instructions for: 
5 determining whether a record of the first database 

has been changed or added since a previous 
synchronization; - " 

if the record of the first database *has not been 
changed or added since the previous synchronization, 

10 sending from the first computer to the second computer 
information which the second computer uses to identify 
the record of the first database to be unchanged, wherein 
a history file located on the second computer contains 
records reflecting the content of records of the first 

15 database at the completion of a previous synchronization 
and said information identifies a record in the history 
file reflecting the content of the record of the first 
database; and 

synchronizing the first database and the second 

20 database using the sent information* 
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21* A computer implemented method for 
synchronizing a first database located on a first 
computer and a second database located on a second 
computer, the method comprising: 
5 determining, at the first computer, whether a 

record of the first database has been changed or added 
since a previous synchronization, using a first history 
file located on the first computer comprising records 
representative of records of the first database at the 

10 completion of the previous synchronization; 

if the record of the first database has not been 
changed or added since the previous synchronization, 
sending from the first computer to the second computer 
information which the second computer uses to identify 

15 the record of the first database to be unchanged. 

22* The computer implemented method of claim 21 
wherein a second history file located on the second 
computer contains records representative of records of 
the first database at the completion of the previous 

20 synchronization, wherein one of the representative 
records represents the record of the first database 
determined to be unchanged, and the method further 
comprises performing a synchronization, at the second 
computer, of the second and first databases using the one 

25 of the representative records. 

23. The computer implemented method of claim 22 
wherein the information sent from the first computer to 
the second computer is used to locate the one of the 
representative records in the second history file. 
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24 ♦ The computer implemented method of claim 23 
wherein the second history file stores information in 
relation to the representative records and wherein the 
one of the representative records in the second history 
5 file can be identified from the stored information. 

25. The computer implemented method of claim 24 
wherein the information sent from the first computer to 
the second computer comprises information that matches 
the information stored in relation to the one of the 

10 representative records in the second history files. 

26. The computer implemented method of claim 21 
wherein the infomnation comprises information identifying 
records other than the unchanged record. 

27. The computer implemented method of claim 21 
15 wherein the information comprises information identifying 

the unchanged record. 

28. The computer implemented method of claim 21 
wherein the information comprises information identifying 
the deleted records. 

20 29. The computer implemented method of claim 21 

wherein the information comprise information identifying 
the added records, 

30. The computer implemented method of claim 21 
wherein the information comprises a code, the code being 
25 based on at least a portion of the content of the record 
of the first database. 
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31, The computer implemented method of claim 30 
wherein the code comprises a hash number computed based 
on at least a portion of the content of the record of the 
first database. 

5 32. The computer implemented method of claim 30 

wherein the information further comprises a first 
plurality of records of the first database identified as 
"changed or added", the method further comprises using 
said information to indentify a plurality of the first 
10 database as "deleted or changed" since the previous 
synchronization . 

33. The computer implemented method of claim 21 
wherein the information comprises a code uniquely 
identifying the records of the first database. 

15 34 • The computer implemented method of claim 33 

wherein the unique identification code is assigned by the 
first database to the records of the first database. 

35. The computer implemented method of claim 34 
wherein the information further comprising a first 
20 plurality of the records of the first database identified 
as "changed", a second plurality of the records of the 
first database identified as added, and information 
identifying a third plurality of records of the first 
database as "deleted". 
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se. A computer implemented method of identifying 

a record of a database stored on a first computer to a 

second computer comprising: 

reading a record of the database; 
5 assigning a code to the record of the database, 

the code being based on at least a portion of the content 

of the record of the first database; 

transmitting the code to the second computer to 

identify the record to the second computer. 

10 37. The computer implemented method of claim 36 

wherein the code comprises a hash number computed based 
on at least a portion of the content of the record of the 
first database. 



38. A computer program, resident on a computer 
15 readable medium for synchronizing a first database 

located on a first computer and a second database located 
on a second computer, comprising instructions for: 

determining, at the first computer, whether a 
record of the first database has been changed or added 
20 since a previous synchronization, using a first history 
file located on the first computer comprising records 
representative of records of the first database at the 
completion of the previous synchronization; 

if the record of the first database has not been 
25 changed or added since the previous synchronization, 
sending from the first computer to the second computer 
information which the second computer uses to identify 
the record of the first database to be unchanged. 



DOCID: <WO 9821648A1_L> 



wo 98/21648 



PCT/US97/20627 



- 66 " 

39. The computer program of claim 38 wherein a 
second history file located on the second computer 
contains records representative of records of the first 
database at the completion of the previous 

5 synchronization, wherein one of the representative 
records represents the record of the first database 
determined to be unchanged, and the program further 
comprising instructions for performing a synchronization, 
at the second computer, of the second and first databases 
10 using the one of the representative records. 

40. The computer program of claim 39 wherein the 
information sent from the first computer to the second 
computer is used to locate the one of the representative 
records in the second history file. 

15 41. The computer program of claim 40 wherein the 

second history file stores information in relation to the 
representative records and wherein the one of the 
representative records in the second history file can be 
identified from the stored information. 

20 42. The computer program of claim 41 wherein the 

information sent from the first computer to the second 
computer comprises information that matches the 
information stored in relation to the one of the 
representative records in the second history files. 

25 43. The computer program of claim 38 wherein the 

information comprises information identifying records 
other than the unchanged record. 

44. The computer program of claim 38 wherein the 
information comprises information identifying the 
30 unchanged records. 
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45. The computer program of claim 3€ wherein the 
information comprises information identifying the deleted 
records. 



46 • The computer program of claim 38 wherein the 
5 information comprise information identifying the added 
records - 



47- The computer program of claim 38 wherein the 
information comprises a code, the code being based on at 
least a portion of the content of the record of the first 
10 database. 



48, The computer program of claim 47 wherein the 
code comprises a hash nun±^er computed based on at least a 
portion of the content of the record of the first 
database - 



15 49. The computer program of claim 47 wherein the 

information further comprises a first plurality of 
records of the first database identified as "changed or 
added", the program further comprising instructions for 
using said information to indentify a plurality of the 

20 first database as "deleted or changed" since a previous 
synchronization, 

50. The computer program of claim 38 wherein the 
information comprises a code uniquely identifying the 
record of the first database. 



25 51. The computer program of claim 50 wherein the 

unique identification code is assigned by the first 
database to the record of the first database. 
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52. The computer program of claim 50 wherein the 
information further comprises a first plurality of the 
records of the first database identified as "changed", a 
second plurality of the records of the first database 

5 identified as added, and information identifying a third 
plurality of records of the first database as "deleted". 

53. A computer program, resident on a computer 
readable medium, for identifying a record of a database 
stored on a first computer to a second computer 
comprising instructions for: 

reading a record of the database; 
assigning a code to the record of the database, 
the code being based on at least a portion of the content 
of the record of the first database; 

transmitting the code to the second computer to 
identify the record to the second computer- 

54. The computer program of claim 53 wherein the 
code comprises a hash number computed based on at least a 
portion of the content of the record of the first 

20 database. 
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55. A computer implemented method of 
synchronizing at least a first and a second database, 
wherein the first database provides information regarding 
records which have been added, deleted or modified since 
5 a previous synchronization, the method comprising: 

storing in a history file records representative 
of the records of the first database after the previous 
synchronization; 

obtaining information regarding the records which 
10 have been modified, deleted, or added since the previous 
synchronization ; 

performing a first comparison of the records of 
the second database with records in history file 
corresponding to records of the first database that have 
15 not been modified, added, or deleted; 

completing the current synchronization based on 
the outcome of the first comparison and the information; 
and 

modifying, adding, or deleting records in the 
20 history file using the information obtained from the 
first database such that the history file contains 
records representative of the records of the first 
database after the current synchronization. 
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"TO- 
SS. A computer program, resident on a computer 
readable medium, for synchronizing at least a first and a 
second database, wherein the first database provides 
information regarding records which have been added, 
5 deleted or modified since a previous synchronization, 
comprising instructions for: 

storing in a history file records representative 
of the records of the first database after the previous 
synchronization; 
10 obtaining information regarding the records which 

have been modified, deleted, or added since the previous 
synchronization; 

performing a first comparison of the records of 
the second database with records in history file 
15 corresponding to records of the first database that have 
not been modified, added, or deleted; 

completing the current synchronization based on 
the outcome of the first comparison and the information; 
and 

20 modifying, adding, or deleting records in the 

history file using the information obtained from the 
first database such that the history file contains 
records representative of the records of the first 
database after the current synchronization. 
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BJ 


Benin 


IE 


Ireland 


MN 


' Mongolia 


UA 


Ukraine 


BR 


Brazil 


IL 


Israel 


MR 


Mauritania 


VG 


Uganda 


BY 


Belarus 


IS 


Iceland 


MW 


Malawi 


US 


United States of America 


CA 


Canada 


IT 


Italy 


MX 


Mexico 


uz 


Uzbekistan 


CF 


Central African Republic 


JP 


Japan 


NE 


Niger 


VN 


Viet Nam 


CG 


Congo 


KE 


Kenya 


NL 


Netherlands 


YU 


' Yugoslavia 


CH 


Switzerland 


KG 


Kyrgyzstan 


NO 


Norway 


ZW 


Zimbabwe 


CI 


C6ic d'lvoire 


KP 


Democratic People's 


NZ 


New Zealand 






CM 


Cameroon 




Republic of Korea 


PL 


Poland 






CN 


China 


KR 


Republic of Korea 


PT 


Portugal 






CU 


Cuba 


K2 


Kazakstan 


RO 


Romania 






CZ 


Czech Republic 


LC 


Saint Lucia 


Rli 


Russian Federation 






DE 


Geimany 


LI 


Liechtenstein 


SD 


Sudan 






UK 


Denmark 


LK 


Sri Lanka 


SE 


Sweden 






E£ 


Estonia 


LR 


Liberia 


SG 


Singapore 
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